home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1120 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.4 KB
  1. From: thp@cs.ucr.edu (Tom Payne)
  2. Message-ID: <4l12rf$q11@galaxy.ucr.edu>
  3. X-Original-Date: 16 Apr 1996 21:18:39 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 17 Apr 96 08:29:22 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.programming.threads,comp.std.c++
  8. Subject: Re: Is STL MT-Safe?
  9. Followup-To: comp.programming.threads,comp.std.c++
  10. Organization: University of California, Riverside
  11. References: <4kmjvj$89t@usc.edu> <4kspmb$9tb@ubszh.fh.zh.ubs.com> <3173E95E.5AC@ix.netcom.com>
  12. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMXSr6+EDnX0m9pzZAQETPgF+OTycFY/pXpmPGcVmYwT3xhJWTsLyeKXz
  15.     ThlXJYwEvcV+fRrSdPGgJXKxb89ldM6A
  16.     =MeI0
  17.  
  18. David Brownell (brownell@ix.netcom.com) wrote:
  19. : > I believe Modena or one of the other commercial STL library vendors has
  20. : > added a certain degree of thread-awareness to their implementation. I
  21. : > might be wrong, but I have a feeling that it is still not entirely
  22. : > thread-safe.
  23. : 
  24. : Someone else mentioned Rogue Wave.  Does anyone have URLS or something
  25. : through which the different "MT-enhanced" APIs could be compared?  I've
  26. : been organizing a collection of MT/C++ issues; one of the gaps is where
  27. : the standard C++ library interfaces need to be "MT-safed" according to
  28. : some useful and consistent policy.
  29.  
  30. Is there agreement on what is meant by the term "thread safe."  (I have 
  31. seen definitions that seemed quite inadequate.)
  32.  
  33. : Eventually, the vendors ought to agree on one way to do threaded C++,
  34. : but we're not there yet!  I don't know how much commonality there is
  35. : between different MT/C++ environments but I suspect it's not lots.
  36.  
  37. The standards process is the appropriate forum for such vendor
  38. agreement.  Unfortunately, the standards bodies have failed to provide
  39. the necessary leadership in the areas involving concurrency and
  40. asynchrony.  Perhaps, these bodies simply have other fish to fry --
  41. getting the current standard completed is an monumental task.  I
  42. detect, however, some reluctance to address matters of concurrency and
  43. asynchrony for fear of:
  44.  
  45.   *  limiting the range of architectures on which the langauge
  46.      in efficiently implmentable,
  47.  
  48.   *  introducing incomapatibilities with vendor-established 
  49.      extensions,
  50.  
  51.   *  commitment to one or another particular model for 
  52.      concurrent programming.
  53.  
  54. Although each of these fears has some arguments for it, the portable
  55. implementations of Modula and Ada offer evidence that the difficulties
  56. are surmountable.  Meanwhile, a C++ program (with defined behavior)
  57. cannot deal efficiently with some of the simplest asynchrony, e.g., a
  58. hardware-detected exception cannot generate a program exception,
  59. unless the program explicitly polls for it, thus, requiring
  60. unacceptable overhead both in running time and programming effort.
  61.  
  62. There have been suggestions that such matters should be addressed by
  63. the C Standards Committees and possibly incorporated by reference into
  64. the C++ Standard by reference.  While it is important to maintain as
  65. much commonality as possible, there are considerations that are unique
  66. to C++, e.g., interaction with exceptions.
  67.  
  68. Tom Payne (thp@cs.ucr.edu)
  69. ---
  70. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  71. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  72. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  73. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  74. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  75.